home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9608 / 000033_owner-urn-ietf _Tue Aug 27 14:56:39 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  3KB

  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA22230 for urn-ietf-out; Tue, 27 Aug 1996 14:56:39 -0400
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA22225 for <urn-ietf@services.bunyip.com>; Tue, 27 Aug 1996 14:56:32 -0400
  3. Received: from oit.gatech.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA07698  (mail destined for urn-ietf@services.bunyip.com); Tue, 27 Aug 96 14:56:26 -0400
  5. Received: (from ccoprmm@localhost) by oit.gatech.edu (8.7.5/8.7.3) id OAA17590; Tue, 27 Aug 1996 14:56:15 -0400 (EDT)
  6. From: Michael Mealling <Michael.Mealling@oit.gatech.edu>
  7. Message-Id: <199608271856.OAA17590@oit.gatech.edu>
  8. Subject: Re: [URN] NAPTR "wizards"
  9. To: weibel@oclc.org
  10. Date: Tue, 27 Aug 1996 14:56:14 -0400 (EDT)
  11. Cc: urn-ietf@bunyip.com
  12. In-Reply-To: <199608271817.OAA01940@ws02-00.rsch.oclc.org> from "Stu Weibel" at Aug 27, 96 02:17:31 pm
  13. X-Mailer: ELM [version 2.4 PL23]
  14. Mime-Version: 1.0
  15. Content-Type: text/plain; charset=US-ASCII
  16. Content-Transfer-Encoding: 7bit
  17. Sender: owner-urn-ietf@services.bunyip.com
  18. Precedence: bulk
  19. Reply-To: Michael Mealling <Michael.Mealling@oit.gatech.edu>
  20. Errors-To: owner-urn-ietf@bunyip.com
  21.  
  22. Stu Weibel said this:
  23. > Ron Daniel writes:
  24. >  > Actually, at the BOF in Montreal, we explicitly said that URNs are not
  25. >  > going to solve the friendly naming problem.
  26. > Dan LaLiberte writes:
  27. > > I would be opposed to a system which made it more difficult
  28. > > than necessary to allow unique names to also be friendly.
  29. > I strongly agree with Dan on this point.  
  30. > We're back to the groundhog day problem... we don't agree what the
  31. > problem is, so we can't agree on the solution.
  32. > NAPTR-based resolution is solving a RESOLUTION problem, not a unique naming
  33. > problem (the solution to which is far simpler, and for which numerous 
  34. > solutions already exist).
  35. > I'm not sure who the "we" was in Montreal that decided on the scope and
  36. > specific nature of the problem.  Attempts to clarify this in the BoF itself
  37. > were sloughed off as obstructionist.  So, here we are again.
  38.  
  39. What we decided was that we weren't going to SPECIFICALLY try and solve
  40. the "the user wants an easy term or phrase to remember so he can reliably
  41. find Apples homepage". That's a directory services problem. If you 
  42. personally want to try and design a URN namespace that tries to solve
  43. this problem then go right ahead. Many of use just don't want to solve
  44. that particular problem as the only problem.
  45.  
  46. -- 
  47. ------------------------------------------------------------------------------
  48. Life is a game. Someone wins and someone loses. Get used to it.
  49. <BR>
  50. <HR><A HREF="http://www.gatech.edu/michael.html">Michael Mealling</A>